I love Cockpit, it's so comfortable to use.

@IRJ said in Doublecheck the Security of Your Linux:

Just a couple notes from the article:

You cannot set a bootloader password for AWS or other cloud services

Apt Armor is specific to Ubuntu / Debian. SELinux is used on RHEL / CentOS / Fedora

AppArmor is default on SUSE as well. And you can run SELinux on Debian / Ubuntu if you want.

BTW, AppArmor just replaced SELinux as default on Debian 10. So that was only a couple of months ago.

Vultr got back to me last week with an email -

"Hello,

We apologize for the delayed response to this ticket, while we investigated this matter further.

We are continuing to review our OS template and application images, and should be applying comprehensive changes across all available deploy images in the near future.

Your continued patience and understanding is appreciated in the meantime.

If you have any followup questions or concerns, please feel free to reach out."

I've done both. I tend to like MariaDB / MySQL better because that is what I'm more comfy with.

@JaredBusch said in Error - SELinux is Preventing Vmtoolsd From Entrypoint Access On the File /usr/bin/bash:

@wrx7m said in Error - SELinux is Preventing Vmtoolsd From Entrypoint Access On the File /usr/bin/bash:

My question - Is this permanent?

Yes

Thanks!

@marcinozga said in Linux partitioning:

@travisdh1 said in Linux partitioning:

@marcinozga said in Linux partitioning:

@travisdh1 said in Linux partitioning:

@marcinozga said in Linux partitioning:

@travisdh1 said in Linux partitioning:

@marcinozga said in Linux partitioning:

@JaredBusch said in Linux partitioning:

@marcinozga said in Linux partitioning:

Last option on that screen. Why? Because if your root partition fills up, your system won't boot. Having /var on separate partition reduces that risk. Think of a bad app creating gigabytes of log entries, or writing junk to database.

Better solution, don't use bad apps

You never know if an app or kernel update doesn't go nuts. Here's an example of bad kernel module causing writing gigs of logs in minutes: https://unix.stackexchange.com/questions/195360/my-var-log-is-mysteriously-filling-up-gbs-in-minutes-any-cure-before-i-re-ins

Sure it's possible, but how many times do we see this sort of thing in normal use day to day? This is the first one I've heard of in years.

Used to happen more often because bad programming was more common.

Take Ubuntu for example, it will fill up /boot after a few kernel upgrades, so anything is possible.

That's a known badly implemented system. IE bad programming. Don't use it.

Also, it has nothing to do with /var filling up.

It's just an example of partition filling up, doesn't matter which one. It proves the point that it does happen.

In your example, they are causing a new problem because they've implemented your solution to the problem.

No, it would've had the same outcome if /boot wasn't on separate partition, but under root. Eventually it would've filled up entire disk with old kernel versions. The main point is to prevent root partition from filling up, not any other mount point.

That's not really true. That's making a lot of assumptions. In reality...

It would not likely ever fill up. The scales are so different. This is where creating a separate /boot actually CREATES the risk. The very pattern you are trying to follow is the one causing the issue.

It has lots and lots of chances for humans AND monitoring systems to catch and resolve it long before becoming an issue. This should have years, typically, to be flagged rather than filling up in a day or two.

@BBigford said:

Looks like there is quite a bit included in the free version for up to 10 premium users, and 10 basic users. Interesting.

Yes, it is quite extensive.

@scottalanmiller

@scottalanmiller said:

We need some latency numbers from around the world. Anyone want to collect some for us?

Here is the first IP address. A long running ping (hundreds or thousands of pings) would be good, we need the final stats from that:

104.236.119.59 108.61.151.173 172.99.75.133

We have a good idea on bandwidth, IO, CPU and memory. Network latency is pretty huge.

1,200,000 packets later...
via rackspace 8 GB General Purpose v1 based in london

--- 162.242.243.171 ping statistics --- 400510 packets transmitted, 400499 received, 0% packet loss, time 400849652ms rtt min/avg/max/mdev = 79.018/79.634/184.775/2.778 ms --- 104.236.119.59 ping statistics --- 400759 packets transmitted, 400732 received, 0% packet loss, time 401132556ms rtt min/avg/max/mdev = 73.663/74.533/191.571/2.203 ms --- 108.61.151.173 ping statistics --- 400765 packets transmitted, 400749 received, 0% packet loss, time 401117767ms rtt min/avg/max/mdev = 69.861/75.792/205.164/3.167 ms

@wirestyle22 said:

@coliver said:

@wirestyle22 said:

I have to look up SSL certification on CentOS 7 now. I've only ever done it on our Barracuda SSL VPN which was just an upload. Here we go

I think you need to look up SSL for Apache if you are trying to encrypt ownCloud. I think someone has a guide on here somewhere about it.

I think @JaredBusch has it in his 8.2 guide. I think he did self signed though. I'm unsure of how to do this on linux with digicert or something similar

It was a self signed for the example. but I use letsencrypt myself. Some clients using ownCloud have StartSSL certs.

I just used this myself to make a new block device in a single line. Awesome 🙂

https://channel9.msdn.com/Shows/Data-Exposed/SQL-Server-on-Linux-Sneak-Peak

@ou_snaaksie said in Installing Rocket.Chat on CentOS 7:

The installation worked perfetly, but after restarting the server I am unable to access Rocketchat.

I've run the line:
/opt/Rocket.Chat/node_modules/forever/bin/forever start /opt/Rocket.Chat/main.js

but it is still not working.

Use this command to see what is listening...

netstat -tulpn

@scottalanmiller said in Installing MongoDB 3.2 on CentOS 7:

Just tested and deployed to CentOS 7.2 on Linode.

This failed me, so I went to the mongo docs and the baseurl contains the variable $releasever.

using that results in redhat//mongodb in the file, which is why I assume you hard coded that bit.

Escaping the $ fixes it.

cat > /etc/yum.repos.d/mongodb-org-3.2.repo <<EOF [mongodb-org-3.2] name=MongoDB Repository baseurl=https://repo.mongodb.org/yum/redhat/\$releasever/mongodb-org/3.2/x86_64/ gpgcheck=1 enabled=1 gpgkey=https://www.mongodb.org/static/pgp/server-3.2.asc EOF

Updated as I figured out where things have moved away from the documentation that I had. The five minute install video is for Stacki 1.x and they have changed quite a bit at the core so that is why the video does not reflect the needs of the current installer. Avoid the StackiQ video for installation.

It is not uncommon to only have servers approved to access the storage listed. So many shops will go in and add a server one by one to enable access. If your servers almost never change, this works pretty well and is extremely secure. You can do this in the firewall too, for even more security. But if you are using DevOps and creating and destroying VMs regularly you will want to automate this in some fashion.

Original post has been updated to reflect the latest 0.9 release of the Minecraft Server.

@clisting said in Installing PocketMine MineCraft PE Server on CentOS 7:

it constantly disconnects me. the server appears to be online please help me.

I've not touched this in three and a half years, I'm afraid. This stuff easily doesn't work any longer 😞